The present invention relates to a system and method for the testing of applications run on a Point-of-Sale (POS) terminal.
Point-of-sale terminals are EDC (Electronic Data Capture) terminals that a merchant uses at the time and place of a transaction to capture purchaser information from credit cards, debit cards, smart cards, and the like.
The terminals may be combined with cash registers, bar code readers, optical scanners and magnetic stripe readers, and may be on-line to a central computer for, for example, credit checking and inventory updating.
Examples of POS terminals include those supplied by Verifone as the TXO(trademark) and Verix(trademark) terminals.
Developers of applications for POS terminals need to test the applications prior to their commercial use in order to debug them, and to ensure that they work properly. To do this, various testing tools are available.
In one such testing tool, the developer connects a PC to a POS terminal through a RS232 serial port, and uses the PC to simulate key inputs and card swipes into the terminal.
The developer writes a script of POS terminal key sequences and card swipes which represent various test cases in a test plan, and these sequences are sent to the POS terminal, where the application under test executes them one after the other. As well as key sequences, the developer can add pauses of differing lengths into the scripts between key presses in order to allow the application under test time to deal with a current key stroke before the next key stroke is simulated.
Using such a test tool, the developer can run various automated test plans on the POS terminal to ensure that all possible key and swipe card inputs are dealt with properly.
Problems can, however, arise with such test tools. For example, even though a test script may include pauses between keystrokes, the supply of the key sequences to the POS terminal may still lose synchronisation with the operations of the POS terminal. This may occur for example due to a slow down in the operations of the POS terminal caused by an increase in the amount of work and volume of data which the POS terminal has to process.
An object of the present invention is to provide an improved system and method for the testing of applications for use in Point-of-Sale terminals.
According to a first aspect of the present invention, there is provided a system for the testing of an application run on a POS terminal, which comprises a host device for sending messages to the POS terminal in accordance with a user""s test procedure, and a target component provided in the POS terminal, which receives and processes the messages from the host device and provides data from the messages to the application under test; wherein the target sends status information to the host to indicate the status of the POS terminal, and the host transfers the messages to the target in accordance with this status information.
Thus, the testing tool of the present invention consists of two parts, a host separate from the POS terminal, and a target within the POS terminal. The host may for example be provided under a Windows(trademark) platform on a personal computer, whilst the target may be a software component found in the POS terminal alongside the application to be tested.
The provision of status information allows for example test key sequences sent from the host to remain in synchronisation with the application running on the POS terminal, as the host can send data to the POS terminal on a need basis in response to the status information provided by the target. The system thus contrasts with the above-mentioned prior art testing tool that pumps data directly into the application on the POS terminal without regard to its status, and attempts to account for synchronisation problems using pauses in the keystroke sequence scripts. In the prior art, the full control of the test was at the computer, and the terminal merely executed the commands sent from the computer without providing any status information to the computer.
In one preferred form, the status information sent by the target is information regarding the screen display of the POS terminal. The host can then time the sending of information to the target in accordance with the screen information. For example, the host may send a card swipe command to the POS terminal, and may then await the display of a screen requesting expiry date information before sending data to simulate the key strokes for this information.
The connection of the host to the POS terminal may take any suitable form, and is preferably a serial connection, such as through an RS232 cable.
The target processes the data sent from the host, and carries out the various requirements necessary for it to be input to the application under test.
Preferably, the host sends data and command messages to the target, and the target determines the type of message received from the host, and then passes data from the data messages to the POS terminal application, or provides information to the host in accordance with the command messages. For example, the target may write data from a host data message to a corresponding buffer of the POS terminal, such as a keyboard or magnetic card swipe buffer, and might provide information as to the file name of a POS terminal file in response to a filename request message.
When the POS terminal is based on an interrupt-driven architecture, the target may issue an interrupt signal after passing data to a buffer, when the POS terminal does not provide a hardware interrupt associated with the buffer, such as for a card swipe buffer.
The host may receive other information from the target. For example, when the POS terminal is based on an events-driven architecture (such as a Verix(trademark) terminal as supplied by Verifone), all of the events occurring in the POS terminal may be sent to the host by the target. Thus, the target preferably monitors an events queue of the POS terminal, and sends information relating to the events popped from the events queue to the host terminal. This information may then be used by a tester to determine what might have gone wrong in a particular test through an inspection of the events followed by the application.
Further information which the host may receive includes: information as to available space in the RAM of the POS terminal; details of files on the POS terminal; and details of the POS terminal""s system clock, e.g. time and date.
The host may also instruct the target means to take a particular action, such as to delete or rename a file, amend the system clock, or reboot and restart the application under test.
Indeed, with an events-based POS terminal, the present invention allows the simulation of any event, as the target is able to put the simulated event, sent from the host, into the events queue of the terminal, so that the event is executed by the application""s event handler on getting the event from the queue.
Preferably, the POS terminal application is configured to include trace statements, which are put into the application for debugging purposes. Such a statement, when executed, prints a string passed to it as an argument in an output source (for example an output/debug window or a COM port). If the application under test includes such statements, then preferably the target passes these trace statements to the host device also.
In a preferred embodiment, each trace statement in the test application is provided with an additional parameter which the host uses to group it with other trace statements. The host may then group all of the trace elements of the same parameter in one window, so that application programmers can have a number of trace statements in their applications without cluttering up the output window on the host device.
The host may be highly configurable with respect to the POS terminals to which it communicates. Preferably, the host includes a look-up table of the input code information that is used by the POS terminal under test, such as key code information, and correlates this information with the tester""s desired simulated input in order to output a suitable simulated code for sending to the target. This allows the system to be used with various POS terminals merely by using a different look-up table. The host may configure the terminal properties, e.g. the number of keys, key code values for each key, the key-pad layout, the terminal processor byte ordering and the like, at run time for each terminal to which it connects.
The target may be configured using a resource file downloadable from the host. Thus, the target may receive instructions on how to configure the communications port of the POS terminal for communicating with the host, e.g. the baud rate used, etc.
The host may provide an interactive interface for the user in the form of the display of e.g. a POS terminal keypad layout or the like. This allows the test engineer to visually and interactively test the POS application. During the test, the host may record the keystrokes and other actions taken, so as to provide record and playback macro support, whereby the test engineer can record the test actions through the interactive mode, and can play the same back again at a later time.
The host may also provide scripting, in which pre-scripted sequences of messages are sent to the terminal to automatically test the terminal. The scripting language used may support looping and branching to user-defined functions, and may take a similar form to C.
Viewed from a further aspect the present invention provides, a method for the testing of an application run on a POS terminal, the method comprising the steps of:
connecting a host device to the POS terminal for interfacing with a user of the system, and transferring messages to the POS terminal in accordance with a test plan provided by the user;
providing a target component in the POS terminal for receiving the messages from the host device and for providing data from the messages to the POS terminal application to be tested; and
sending status information from the target to the host to indicate the status of the POS terminal, and sending messages from the host to the target in accordance with the status information to test the application.